Would this be diverse enough to make technical decisions? I wonder if it's necessary to form a TOC. An alternative would be getting a list of people from WG leads.

I propose that we should initially have 5 TOC members. Perhaps 2 members will be initially for 1 year terms.

WG leads being also TOC members would risk creating conflicts of interest and not encourage enough diversity in ideas and approach. I think starting with 3 now and adding 5 within a 12 month timeframe is a good approach

I agree with @jbottum and @StefanoFioravanzo

Do we need to control max number of people from each organization similar to what we do for KSC?

@terrytangyuan Sure, let me add this point.

Typo: says deleted

This sounds like a top down approach. We have not used this in the Kubeflow community as the WG have set their own directions and roadmaps. Perhaps, we should consider a different word than "Set". I don't know if Socialize or Consolidates are the potentially closer word.

I like this idea. For eg: TOC can look at interesting directions for Kubeflow as a whole like LLMOps in the current space. TOC can plan right technical directions to the reach the overall goal like discussing with different stakeholders, Working Groups for better alignment

Perhaps the words are "Consolidate and Validate"

I can think of the TOC as a "Consulted" party when WGs work on design docs, new architectures, challenging implementations etc. From an "integrated product" point of view, I believe the TOC should be responsible to suggest cross-WG end-to-end architecture and user experience roadmap. Each WG would be responsible to take those recommendations in and work with TOC as a partner to align on their plans.

I agree with you @jbottum, that was my initial thinking. Let me re-word it.

@jbottum @StefanoFioravanzo @johnugeorge Added the following statements:

- Consolidate together with WGs the overall technical direction and Kubeflow roadmap.
- Suggest cross-WGs features like LLMOps and work with stakeholders to address it.

I like this goal but I am not sure how the TOC fits in. Most issues will be at the WG level and theirs to resolve. Will the TOC be responsible to resolve or just additional contributing resources under direction of the WG

I think we should define what "stability" means. Is this about CICD and testing infrastructure? Defining testing targets, automation pipeline guidelines and recommendations may be well in scope for the TOC

I think, stability covers all of this @StefanoFioravanzo. Also, we can say about Kubeflow LTS. Should we explicitly add it to charter ?

Oh you bring up a good point! We could add another bullet along the lines of "- Define a long term support (LTS) community SLA and support WGs for security escalations and critical bug fixes"

I believe the Release Manager has been the final authority for a release. We can change but perhaps the final authority / decision maker needs to be defined. I believe we can have many inputs and influencers, but only 1 decision maker.

+1

+1 - Agree. The TOC will definitely influence what WGs decide to implement and propose in their roadmap, but ultimate accountability for roadmap readiness should be on the release team

@jbottum @StefanoFioravanzo @johnugeorge Any thoughts on who should be the final authority for Kubeflow releases and what role TOC should play in addition to just a guidelines and suggestions ?

Depends on whether we want to make the TOC just a "consulted" party or ultimately accountable for the roadmap. Being the primary technical body, I am inclined to say that the TOC should have final approval of the roadmap proposed by the release manager/team. This could become a new action item in the release handbook.

Another way to look at this is: pushing accountability to the Release Manager could be done by having the TOC appoint the Release Manager in the first place, delegating that responsibility.

Maybe let's look at how other communities are doing this

We should consider time limits for topics and a best practice for when a formal issue or PR must be created ?. In order to drive for decisions, we should define a process for requesting a vote i.e. can we take a vote before discussion, and at the 10 minute mark or other? In addition, if a member objects to the vote results, what is the process to continue the conversation i.e. does the objecting member need to provide a plan to deliver more information before the discussion can continue.

I agree with you @jbottum, any suggestions on how we can express it in the charter ?
For example, when making changes to the TOC charter we give at least 1 week community to provide comments: https://github.com/kubeflow/community/pull/701/files/5d5a3e473d464b9a036e527040e62adaaa86577c#diff-6a27463fa3d59d96139352472c4244cd45e5fd103c80fc00d5fe320b7c04ca76R183-R184

The meeting process should include:

Topics should be submitted in the form of a question, which can be voted on.

Topics can be prioritized by the meeting host.

Topics can be reviewed at the beginning of the meeting.

Topics should be addressed one at a time, unless there is a dependency that needs to be considered.

After stating the issue, the host should ask for a non-binding vote.

If there is consensus, then the host can ask for a 2nd to make the vote binding.

After the vote, any member can ask for a discussion period, which by default is ten meeting or less.

After discussion, the host will confirm consensus and/or ask for a vote.

The vote will be recorded.

If member(s) abstain because they need more information, the issue will be documented with the additional information needed before it can be addressed as topic again in a future meeting. If the information is not provided within 2 weeks, a member can ask for a binding vote in the next meeting.

Sounds good. I added it @jbottum

I think we should define what "stability" means. Is this about CICD and testing infrastructure? Defining testing targets, automation pipeline guidelines and recommendations may be well in scope for the TOC

It's unclear to me what is the proposed scope for the KTOC - do responsibilities stop at (software, infra) architecture & implementation, security, development guidelines) or do they include product design, usability, UX, user research activities? Some bullets below (e.g. cross-components integration, roadmap oversight) seem to imply a larger focus.

Also, when saying "set the overall technical direction and Kubeflow roadmap" we need to think how that direction is influenced. Generally these decisions are informed by a higher level product design and research that takes into account user feedback, UX research etc. Where does this input come from? It's either from the TOC itself (then the TOC is responsible for those activities) or from a different appointed entity.

These are good points @StefanoFioravanzo. Ideally, we should have various teams dedicated to UX, user feedback, security, guidelines, etc. We are not there yet. That is why initially folks on TOC should be multi-tasking to address various topics. Once we have enough people dedicated to the specific topic, TOC can delegate those tasks to them. What do you think @StefanoFioravanzo ?

@andreyvelich I agree and I think we should make this explicit in the charter, especially if the end goal is to delegate these responsibilities to a new group (which I agree should be the case). Actually, the chart could indicate that one of the TOC medium/long-term goal is to drive the creation of such groups.

WG leads being also TOC members would risk creating conflicts of interest and not encourage enough diversity in ideas and approach. I think starting with 3 now and adding 5 within a 12 month timeframe is a good approach

Would it make sense to require unanimous consensus while the group is composed of 3 members, and then switch to rounded half when the group expands to 5?

Might make sense if we agree on 3 members. Another solution could be to ask KSC to participate in TOC decision process until we have 5 members. Any thoughts @jbottum @johnugeorge @thesuperzapper ?

Asking the KSC to participate may overload the KSC - but hey it would be a KSC decision :)